The Solution: Component Software
Object-oriented programming has long been advanced as a solution to the
problems at hand. However, while object-oriented programming is powerful, it has
yet to reach its full potential because no standard framework exists through
which software objects created by different vendors can interact with one
another within the same address space, much less across address spaces, and
across network and computer architecture boundaries. The major result of the
object-oriented programming revolution has been the production of "islands of
objects" that can't talk to one another across the sea of application boundaries
in a meaningful way.
The solution is a system in which application developers create reusable
software components. A component is a reusable piece of software
in binary form that can be plugged into other components from other vendors with
relatively little effort. For example, a component might be a spell checking
feature sold by one vendor that can be plugged into several different word
processing applications from multiple vendors. It might be a math engine
optimized for computing fractals. Or it might be a specialized transaction
monitor that can control the interaction of a number of other components
(including service providers beyond traditional database servers). Software
components must adhere to a binary external standard, but their internal
implementation is completely unconstrained. They can be built using procedural
languages as well as object-oriented languages and frameworks, although the
latter provide many advantages in the component software world.
Software component objects are much like integrated circuit (IC)
components, and component software is the integrated circuit of tomorrow. The
software industry today is very much where the hardware industry was 20 years
ago. At that time, vendors learned how to shrink transistors and put them into a
package so that no one ever had to figure out how to build a particular discrete
function—an NAND gate for example—ever again. Such functions were made into an
integrated circuit, a neat package that designers could conveniently buy and
design around. As the hardware functions got more complex, the ICs were
integrated to make a board of chips to provide more complex functionality and
increased capability. As integrated circuits got smaller yet provided more
functionality, boards of chips became just bigger chips. So hardware technology
now uses chips to build even bigger chips.
The software industry is at a point now where software developers have
been busy building the software equivalent of discrete transistors—software
routines—for a long time.
The Component Object Model enables software suppliers to package their
functions into reusable software components in a fashion similar to the
integrated circuit. What COM and its objects do is bring software into the world
where an application developer no longer has to write a sorting algorithm, for
example. A sorting algorithm can be packaged as a binary object and shipped into
a marketplace of component objects. The developer who need a sorting algorithm
just uses any sorting object of the required type without worrying about how the
sort is implemented. The developer of the sorting object can avoid the hassles
and intellectual property concerns of source-code licensing, and devote total
energy to providing the best possible binary version of the sorting algorithm.
Moreover, the developer can take advantage of COM's ability to provide easy
extensibility and innovation beyond standard services as well as robust support
for versioning of components, so that a new component works perfectly with
software clients expecting to use a previous version.
As with hardware developers and the integrated circuit, applications
developers now do not have to worry about how to build that function;
they can simply purchase that function. The situation is much the same as when
you buy an integrated circuit today: You don't buy the sources to the IC and
rebuild the IC yourself. COM allows you to simply buy the software component,
just as you would buy an integrated circuit. The component is compatible with
anything you "plug" it into.
By enabling the development of component software, COM provides a much
more productive way to design, build, sell, use, and reuse software. Component
software has significant implications for software vendors, users, and
corporations:
- Application developers are enabled to build and distribute
applications more easily than ever before. Component objects provide both
scalability from single processes to enterprise networks and modularity for
code reuse. In addition, developers can attain higher productivity because
they can learn one object system for many platforms.
- Vendors are provided with a single model for interacting with other
applications and the distributed computing environment. While component
software can readily be added to existing applications without fundamental
rewriting, it also provides the opportunity to modularize applications and to
incrementally replace system capabilities where appropriate. The advent of
component software will help create more diverse market segments and niches
for small, medium, and large vendors.
- End-users will see a much greater range of software choices,
coupled with better productivity. Users will have access to hundreds of
objects across client and server platforms—objects that were previously
developed by independent software vendors (ISVs) and corporations. In
addition, as users see the possibilities of component software, demand is
likely to increase for specialized components they can purchase at a local
software retail outlet and plug into applications.
- Corporations benefit from lower costs for corporate computing,
helping IS departments work more efficiently, and enabling corporate computer
users to be more productive. IS developers will spend less time developing
general purpose software components and more time developing "glue" components
to create business-specific solutions. Existing applications do not need to be
rewritten to take advantage of a component architecture. Instead, corporate
developers can create object-based "wrappers" that encapsulate the legacy
application and make its operations and data available as an object to other
software components in the network.
Send feedback on this article. Find support options.
© 2001 Microsoft Corporation. All rights reserved. Terms of
use.